Thanks for your contribution. Can you send me the prompts you used to generate this PR? that would be very helpful.

Hi @sliverc

Me:

Last week or before, I don't remember exactly, we installed copyq to replace diodon because it stopped working, but I really don't like copyq which works poorly compared to diodon. Remove copyq and either figure out why diodon doesn't work here when it works on another of my machines.

Claude response:

I'll first check the current state of CopyQ and Diodon on this machine.
[Checked system, found CopyQ running, Diodon not installed]
OK, clear situation: CopyQ is installed and running, Diodon is not installed but available in repos. Cinnamon 6.6.7 on X11.
Let's first try to install Diodon and get it working, before removing CopyQ.
[Installed Diodon, launched it]
Diodon installed. Let's try launching it to see if it works.
[Found Diodon spinning at 100% CPU]
Problem identified: Diodon consumes 91% CPU. It's a known bug. Let me investigate.
[Used GDB backtrace, found the issue]
Found the problem! Diodon is stuck in a catastrophic regex (pcre2_match_8 → g_regex_replace_literal) during clipboard menu construction. A clipboard history item is causing infinite backtracking in the regex engine.
The solution: clear the Diodon history.
[Cleared Zeitgeist database history]
Still 100% CPU even with empty history! The bug is in the Diodon code itself, not the data.
[Further investigation, tested with different item counts]
The problem appears between 20 and 30 items. There's a specific item causing the block. Let me identify it.
[Analyzed the issue more deeply]
With recent-items-size=0, Diodon runs at 0% CPU! The problem is loading recent items.
[Tested incrementally: 5, 10, 20, 30, 40, 50 items]
The problem appears between 20 and 30 items.
[Decided to nuke and rebuild Zeitgeist DB]
The user is asking to clear the history. Let's do this properly.
[Backed up and deleted Zeitgeist DB (297MB freed), restarted clean]
Diodon runs at 0% CPU with empty history! Let's test functionality.
[Tested clipboard capture, stress-tested with 30 items]
Perfect, 37 items and 0% CPU. Now let's remove CopyQ.
[Removed CopyQ, added Diodon to autostart]
Done. CopyQ removed, Diodon working at 0% CPU with autostart configured.

Me:

Can you propose a fix to the community?

Claude response:

Good idea. Let me first understand the code to patch properly, then prepare the issue and fix.
[Analyzed Vala source code, identified two root causes]
Root cause identified:

    TextClipboardItem.get_label() processes the ENTIRE text through PCRE2 regex (via string.replace(" ", " ")) before truncating to 50 characters. For a 74KB text item, this is extremely wasteful.
    ImageClipboardItem.with_payload() fully decodes each PNG into a Gdk.Pixbuf immediately on construction. With 50 items including multiple 100KB-1MB images, this decodes tens of MB of PNG data on every menu rebuild.

[Attempted to create GitHub issue - issues disabled]
Issues are disabled on GitHub. Let me check if they accept PRs.
[Found PRs are accepted, forked repo, created fix branch]
The project accepts PRs! I'll create a PR with the fix.
[Implemented fixes for both issues, tested compilation]
Fix 1 (text): Truncate to 200 bytes before processing, use split()/joinv() instead of regex-based replace()
Fix 2 (images): Lazy pixbuf loading - extract dimensions/checksum at construction, but defer full PNG decode until actually needed
Compilation OK.

Thanks a lot. This is very helpful. In Diodon did you activate "add images to clipboard histroy' setting? Do you remember? By default it is turned off.

yes @sliverc
I've enabled "image to clipboard", very useful for me

OK most likely images are causing the problem.

Question: You wrote in the prompt that "diodon stopped working". What did you noticed that it stopped working? It would not start at all or taking a long time? Or was their another problem when opening the menu...?

Diodon was running in the background but completely unresponsive. The keyboard shortcut (Super+V) would not open the menu at all. Command-line verification showed the diodon process was consuming 100% CPU permanently (not just temporarily during startup).

Thanks. I assume copying of a large image caused this. For now I recommend you disable adding images to clipboard history and I will look into it to see how to improve it.

I have implemented some optimization when processing large clipboard items in #50 #51 and #52

This should improve the performance but it is to be noted that adding images to the clipboard by its nature will use more memory as if this option is disabled (hence it is off by default).

The new version can be tested through the daily ppa with the version 1.14.0-daily which should be available soon.

Hi @sliverc, thanks for the fixes in #50 #51 #52! I've rebased my branch on top of your changes.

However, I believe two performance issues remain in the current upstream code:

1. TextClipboardItem: _label = _text copies the entire string before truncating

In #50, the label computation does:

_label = _text;  // copies the entire string (could be 74KB+)
if (_label.char_count() > 50) {  // char_count() walks the entire UTF-8 string

char_count() iterates through every byte to count UTF-8 characters, which is O(n) on the full text. My fix truncates to 200 bytes first (enough for 50 UTF-8 chars at 4 bytes max), so all subsequent operations work on a small buffer:

string label_text = _text;
if (label_text.length > 200) {
    label_text = label_text.substring(0, 200);
}
_label = string.joinv(" ", label_text.split("\n"));

Also, _label.replace("\n", " ") in your version still goes through g_regex_replace_literal() / PCRE2 on the (potentially full) string before truncation. Using split("\n") + joinv(" ") avoids the regex engine entirely.

2. ImageClipboardItem.with_payload: full PNG decode on construction

In #52, with_payload() still decodes the entire PNG payload into a Gdk.Pixbuf immediately:

Gdk.PixbufLoader loader = new Gdk.PixbufLoader();
loader.write(payload.data);
loader.close();
_pixbuf = loader.get_pixbuf();  // full decode of every image

With 50 clipboard images (100KB-1MB each), this decodes tens of MB of PNG data on every startup. My fix stores the raw payload and defers the decode until the pixbuf is actually needed (paste, icon display):

_raw_payload = payload;
_pixbuf = null;
// ...
private Gdk.Pixbuf ensure_pixbuf() {
    if (_pixbuf != null) return _pixbuf;
    // decode only when needed
}

Since you already pass label and checksum to with_payload() in #52, the pixbuf is no longer needed at construction time at all — we can skip the decode entirely.

I've rebased my PR to only contain these two remaining optimizations on top of your work.